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METHODS AND APPARATUS FOR CONTROLLING PROCESSING ENTITIES, SUCH 
AS DISTRIBUTED SIGNALLING GATEWAYS 

BACKGROUND OF THE INVENTION 

5 

Field of the Invention 

The invention relates to methods, and related apparatus, for controlling processing 
entities used, for instance, in communication systems such as for the control of signalling 
1 0 traffic between a distributed signalling gateway and application server processes. 

Background Art 

Establishing connections between two telephones involves a complex interaction of 
15 digital messages, hereinafter referred to generally as signalling. Nowadays telephone 
systems perform what is known as "out-of-band" signalling. Out-of-band signalling means 
that the communications required between the switches and other equipment in the network 
take place on communication channels other than the channel by which the voice or data 
flows- Typically, the out-of-band signalling takes place by means of digital communication 
20 channels. Thus, the public switch telephone network (PSTN) generally uses two types of 
channels, media and signalling. 

Several protocols have been defined for out-of-band signalling. The most commonly 
used protocol, in North America, Asia and Europe, is known as Signalling System No. 7 
25 (SS7). However, the SS7 protocol defines more than just a protocol for communication 
between switches. It also defines an entire switching network for facilitating signalling for 
call establishment, routing, and information exchange functions of switched circuit networks. 

Since the amount of data transferred over data networks is now much larger than the 
3 0 voice traffic that is carried over the PSTN, carriers are willing to consolidate both types of 
networks. Therefore, there is a trend in the telephone industry to migrate telephone systems 
using SS7-based networks for signalling to Internet Protocol (IP) networks. The Internet 
protocols are standardised by the Internet Engineering Task Force (IETF). Moving either or 
both of the media and signalling channels to an IP infrastructure involves the use of very 
3 5 different technologies and can be done independently. One IETF working group, called the 
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Sigtran Group, is focussing on protocol definitions for back-hauling SS7 signalling messages 
across IP networks. 

The following discussion is premised upon one of ordinary skill in the art having a 
5 working understanding of the character and format of switching signals in SS7 networks, as 
well as the character and nature of converting SS7 signals for transport across IF networks. 
The IETF in collaboration with the Sigtran group have taken the initiative to define open 
standards for transporting SS7 over IP networks. With Sigtran technology, telephone 
services which today lie on top of SS7 networks, can run Application Servers (ASs) lying on 
1 0 top of IP networks. The interworking with SS7 networks is performed by Sigtran signalling 
gateways also referred as SGs. 

The evolution to IP based infrastructures is driven by cost reduction, but it will 
happen only if Sigtran technology can be shown to be as reliable as the incumbent SS7 
1 5 technology. For additional information regarding SS7 network switching over IP networks, 
reference may be made to the (IETF) working drafts "SignaUmg Connecting Control Part 
User Adaptation Layer (SUA) " available from the IETF website at www.ietf.org , which is 
incorporated herein by reference as if reproduced in full. 

20 Likewise, reference may be made to the IETF RFC 3332 "SS7 MTP3 - Us er 

Adulation L ayer (M3UAV\ available from the IETF website, and which is incorporated 
herein by reference as if reproduced in full. It is noted that each of these IETF documents is a 
work in progress and is therefore subject to change. However, these documents exemplify to 
one of ordinary skill in the art the changes necessary to a standard SS7 signalling system for 

25 its implementation in an IP networks context. Even though the following description focuses 
on implementing a distributed M3UA signalling gateway, it should also be kept in mind that 
the same techniques also apply to SUA signalling gateways. 

For additional information regarding Sigtran protocols, reference may be made to 
30 the International Engineering Consortium, in document "SS7 Over IP Signalling Transport 
and SCTP ," which is available from the IEC websitewww.iec.org, and which is incorporated 
herein by reference as if reproduced in full. 

Figure 1-A shows a block diagram illustrating a system migration operating under 
3 5 the SS7 protocol to a SS7 system using IP protocol. Before the migration, the SS7 Signalling 
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End Point (SEP) 10 is connected to the SS7 Applications 12 identified by a SS7 User Part 
and a SS7 Stack through a SS7 network 1 1 . Since the Sigtran framework architecture defines 
several functions required to backhaul SS7 Applications on an IP network 24, after migration 
over the IP network, communication between the SS7 Stack of signalling gateway 22 and 
SS7 User Part of the Application Server 26, 28 is established through an IP SCTP network 
24, where SCTP stands for Stream Control Transfer Protocol; More particularly, 
communication is established through their respective M3UA layers. On the other side of 
signalling gateway 22, communication between SS7 Stack 22 and SS7 SEP 20 reinains 
unchanged and is established through the SS7 network 21. 

As is known in the prior art, a Signal Transfer Point (STP) routes SS7 signalling 
within the SS7 network and manages various signalling links which comprise the SS7 
network. Routing is accomplished by processing of the routing label of an SS7 message by 
the Message Transfer Part (MTP) functionality of the signalling point. The MTP layers 
comprise three levels. Levels 1 and 2 are used for the transfer of SS7 messages from one 
point to another over an individual signalling link. Level 3 is used for the transfer of SS7 
messages over the SS7 network beyond the requirements of individual link transmission. The 
MTP3 layer is mainly dedicated to ensuring the delivery of incoming and outgoing messages 
(such as discrimination, distribution and muting), and the network reconfiguration (such as 
traffic management, route management and link management). In brief, levels 1 and 2 are 
used for transport over individual links whereas level 3 is used for transport over the SS7 
network in general. 

Signalling Gateway 22 terminates SS7 lower layers and encapsulates their payload 
data into SCTP (Stream Control Transfer Protocol) messages to send them to an Application 
Server 28, 26, shown in Fig IB. Communication between Signalling Gateway Processes 
(SGPs) of the SG 22 and Application Server Processes (ASPs) is done using the transport 
layer defined by (he Sigtran working group and referred to as SCTP. The AS terminates the 
SCTP, processes the signalling messages and replies to the SG in the same way. 

However, in the SS7 network 21, messages are not transported over SCTP. 
Therefore, the SG 22 is responsible for terminating MTP leveD of the SS7 protocol and 
offering an IP-based extension to its users. In the case of SS7 and M3U A interworking, the 
M3UA adaptation layer is designed to provide an extension of the MTP3 layer. 
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Figure 1-B illustrates the SUA case with backhauling of a Signalling Connection 
Control Part (SCCP) sub-system over the IP network. This sub-system is identified by a 
Routing Key (RK), which has to comply with a set of rules that apply to an SCCP header. 
More specifically, a Routing Key describes a set of SS7 parameters and parameter values 
5 that uniquely define the range of signalling traffic to be handled by a particular Application 
Server, Parameters within the Routing Key cannot extend across more than ft single 
Signalling Point Management Cluster. Each signalling packet processed by the SG, and 
which matches this Routing Key, is forwarded to the corresponding ASP and each AS is 
identified by a Routing Key that describes the types of services that arc being provided- 
1 0 Routing Key RK and Transmission Id TTD play the same roles respectively for the AS and 
the ASP- 

Figure 1-B shows a basic configuration of the different layers of the layered protocol 
communications schemes of the different network elements: a Signalling Gateway Process 

15 SGP 22, a Signalling End Point SEP 20 and an Application Server Process ASP 26. 

Signalling Gateway Process SGP 22 provides an interworking function between an SS7 
network connected to Signalling End Point SEP 20 and an IP network connected to 
Application Server Process ASP 26. Signalling Gateway Process 22 communicates with the 
Signalling End Point through the use of MTP2 and MTP3 layers, and a SCCP layer which 

20 communicates with a Nodal Interworking Function (NIF). The Nodal Interworking Function 
is in effect the highest level software program performing the signalling gateway functions. 
Signalling Gateway Process 22 has a corresponding -set of protocol layers (IP, SCTP and 
M3UA or SUA). Rather than an M3UA layer on top of a SCTP layer, it is possible to use the 
SUA layer. Furthermore, embodiments using other Sigtran adaptation layers such as TUA 

2 5 and the like can also be implemented according to the present invention. 

The Signalling End Point 20 has a structure similar to the Signalling Gateway 
Process 22 apart from the additional two layers TCAP and MAP. TCAP is the protocol layer 
which ultimately interprets the commands and sends responses to the Signalling End Point 

30 20. On the other side of the network, in the same way, the Application Server Process 26 has 
essentially the same layer arrangement as the Signalling End Point 20 and additionally 
includes on top of the SCCP layer, TCAP and MAP layers. The MAP and TCAP layers of 
the Signalling End Point 20 may be directly connected to MAP and TCAP layers of 
Application Server Process 26. Tt will be understood that the TCAP and MAP layers are 

35 described here merely as examples of protocols lying on top of MTP3 and SCCP layers. 
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Furthermore, there are additional differences between IP networks and SS7 
networks. Sigtran defines User Adaptation Layers (UAs) as follows: 

- M2UA and M2PA: when SS7 is terminated at layer2, MTP3 messages are encapsulated 
5 into M2UA (or M2PA) over SCTP. 

- M3UA: when SS7 is terminated at laycr3, user part messages are encapsulated into M3UA 
over SCTP. The User part can be ISUP, SCCP 

- SUA: when SS7 as terminated at the SCCP layer, application part messages are 
encapsulated into SUA over SCTP. The Application part can be for example TCAP or 

10 RANAP. 

- TUA: when SS7 is terminated at TCAP layer, TCAP payloads are encapsulated into TUA 
over SCTP. 

Generally speaking, signalling across an IP network involves replacing the lower 
15 levels of the SS7 layered protocol communications and transport layers with BP network 
protocol communications and transport layers. 

As well as defining the functions of signalling gateways and signalling gateway 
processes, the Sigtran documents referred to above specify in detail the protocols to be 
2 0 implemented between an SGP and an ASP in a single SGP environment. 

To enhance the availability of the signalling gateway, it can be distributed over 
several processes running in one or several computers, each of tbem being a Signalling 
Gateway Process (SGP). 

25 

Every SGP belonging to a particular SG has the same SS7 point code (or the same 
list of PCs), with each SGP being connected to the SS7 network through redundant links. 

On the IP side, each SGP is connected to the ASPs running the services. One AS, 
30 meaning one logical service, can be implemented by one or more processes or computers: 
the ASPs. To provide improved reliability, each SGP may be connected to each ASP through 
an SCTP association such that there is only one association between each SGP and ASP. 

Protocol extensions and procedures have been proposed for implementing a fail-over 
35 mechanism between Stream Control Transfer Protocol (SCTP) associations connecting 
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processes in the Application Servers and processes in the Signalling Gateways. They are 
defined by the IETF in a draft "Correlation Id and Hearbeat Procedures (CORID1 Supporting 
Lossless Fail-Over between SCTP Associations for Signalling User Adaptation Laver?? ' 
available from the IETF website at www.ietf.org. This fail-over mechanism requires both 
5 sides of the associations namely the AS and SG to use a parameter called correlation 
identification CORID that is added into messages exchanged between the Application 
Servers and Signalling Gateways. These messages are, for instance, ASP-ACTTVE, ASP- 
ACnVE-ACK, HEARTBEAT and HEARTBEAT ACK messages. 

1 0 1116 CORK) ID is used by a traffic diversion procedure to ensure that no messages 

will be lost and that messages will delivered in sequence as is required by the standards. 

SUMMARY OF THE INVENTION 



15 



20 



25 



In at least a preferred embodiment , this invention provides a method of controlling a 
local process that forms part of a first processing entity, said first processing entity mamtaimng 
a plurality of associations with a plurality of remote processes in a second processing entity, , 
said method comprising the steps of: receiving a failure message from a remote process 
indicating a fault affecting an association hnkmgthe local process with that remote process; 
queueing data messages destined for that remote process; controlling the transmission of an 
acknowledgement of the failure message so that data messages pending on the association are 
received at that remote process before the acknowledgment of the failure message; and 
initiating a traffic diversion to setup an alternate path between said first processing entity and 
said second processing entity for queued data messages. 



The invention can be applied, for instance, to provide a foilover mechanism where 
the first processing entity is a signalling gateway and the second processing entity is an 
application server. In such an application, the local processes can be signalling gateway 
processes having a common point code or set of point codes and the remote processes can be 
3 0 application server processes having a common routing key. The message indicating the fault 
can be, for instance, an ASP INACTIVE or ASP_DOWN message and the 
acknowledgement being respectively an ASP_INACTTVE_ACK message or an 
ASPJDOWNACK message. 
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The controlling can comprise delaying the acknowledgment of the failure message 
for a predeterminable time period, for instance. The delay can be determined by 
transmission and acknowledgment of a heartbeat message. Alternatively, the controlling 
may comprises sending the acknowledgement of the failure message on the data stream used 
5 for the data messages. 

The first processing entity can maintain a plurality of associations between a 
plurality of local processes and a plurality of remote processes and the method can comprise 
informing other local processes of the fault so that such other local processes can avoid 
10 involving the failed association in traffic diversion procedures initiated by them. 

In preferred embodiments the method comprises determining whether pending 
messages form part of a stateful transaction, as is the case for TCAP messages, and, if so, 
finding an alternative local process to provide an alternative path to the same remote 
1 5 process. 

The method can comprise the initiating of a switch back procedure to include a new 
association linking a local process with a remote process; 

2 0 In other aspects , the invention provides a computer program code element for 

controlling a local process using the above describedmethods and a signalling gateway 
comprising a plurality of local processes that are controlled using such methods. 



25 



BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the invention will now be described, by way of example 
only, with reference to the accompanying drawings in which: 

Figure 1-A shows a prior art system operating under the SS7 protocol and its migration to an 
30 IP network. 

Figure 1-B shows a basic configuration of the different layers of the layered protocol 
communications schemes of a Signalling End Point, a Signalling Gateway Process and an 
Application Server Process. 

35 
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Figure 2 shows one embodiment of a distributed signalling gateway environment in which 
the present invention is implemented. 

Figure 3 illustrates a block diagram of one example of a traffic diversion algorithm example 
5 in a two-SGFs environment showing the search for an alternate path. 

Figure 4 illustrates an example of the implementation of routing tables in an environment of 
two-SGPs showing the association SGP-ASP before failure. 

1 0 Figure 5 illustrates an example of the implementation of routing tables in an environment of 
* two-SGPs showing the association SGP-ASP after failure. 

Figure 6 illustrates a TCAP traffic diversion in case of one failure in an environment of fou* 
SGPs. 

15 . . .. 



Figure 7 illustrates a TCAP traffic diversion in case of two failures in an environment of 

four-SGPs. r 

Figure 8 shows an example of an inter-SGPs communication flow in case of a traffic 
20 diversion procedure in an environment of four-SGPs. 

Figure 9 shows an example of an inter-SGPs communication flow in case of a switch back 
procedure in an environment of four-SGPs. 

2 5 Figure 10 shows a flow diagram of one example of a traffic diversion algorithm. 

Figure 1 1 shows a flow diagram of one example of a switch back algorithm. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

30 

Throughout the specification, and in the claims, the term "application server 
process" refers to a piece of hardware, such as a computer or server, running software to 
perform a task and communicating with other devices and/or programs over a 
communication channel. Further, reference to an "application service" means a software 
3 5 program running on hardware (an application server process) to perform a task related to the 
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telephone network, such as (but not limited to) toll free number translation, mamtainmg 
home location registers, and maintaining visitor location registers. 

Figure 2 shows a distributed SGP signalling gateway 22 configured according to an 
5 embodiment of the present invention to enhance the availability of the signalling gateway. 
Indeed it is possible to distribute several Signalling Gateway Processes (SGPs) in one or 
more computers. An SGP is a process instance of a Signalling Gateway. It serves as an 
active backup, a load-sharing or a broadcast process of the Signalling Gateway. Each 
Signalling Gateway Process 22-1, 22-2 belonging to the same Signalling Gateway 22 has the 
10 same SS7 point code (or the same list of PCs). A signalling gateway appears to the SS7 
network as an SS7 signalling point. Each Signalling Gateway Process 22-1, 22-2 can be 
connected to the SS7 network 21 through redundant links and is actively processing the 
traffic over the network. 

15 On the Internet Protocol network 24 side, each Signalling Gateway Process 22-1, 22- 

2 is connected to the Application Server Processes 26, 28 running the application services. 
Each Application Server 30, 32, meaning each logical service, can be played by one or 
several Application Service Processes 26, 28. To provide improved reliability, each 
Signalling Gateway Process 22-1, 22-2 may be connected to each Application Service 

20 Process 26, 28 through many Stream Control Transfer Protocol SCTP associations. Each 
association is defined as a transport connection between a Signalling Gateway Process SGP 
and an Application Server Process ASP. 

In order to build a more reliable distributed system, the different causes of failure 
25 need to be analyzed and procedures defined to recover from each of these failures. 

The SS7 standards and the Sigtran IETF documents have defined recovery 
procedures for three cases of failure in a distributed SGP environment. 

-Any failure of the SS7 links between an SGP and the 1st SS7 network node (Signalling 
30 Transfer Point) can be recovered by using the procedures as defined for layers MTP2 and 
MTP3. 

-Any failure of any Signalling Gateway Process in the Signalling Gateway respectively with 
can be recovered on the SS7 side and the Sigtran side respectively by SS7 standards and by 
Sigtran IETF documents as defined in the ASP procedure. 
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Jeas «. be recovered by Sibling Con«ol TVansfcr Ptottcol .nulb-honun* - W* 

Hoover, in » disbibuted SGP environment, .here ere two cases of Mures for which 
«. SS7 sfcndatds the S,*ran IETF documents « siient The SS7 network doe, ^havea 

^ the re^uenchtg o, tneasases. The^hre, ,f . 

^ i, ***** » cbecW that messe.es ere no. depicted - lost, ^ *™£ 
fcjfr trenstnmed «. sen. before s^rtin, <o buffer new income ~, 
to . dLbuted SOP environment, when these «wo « *" ^ 

«, only e nafflc diversion procedure b* e.so e svd«ch back procedure » order to recover. 
These two cases of failure are as follows: 

. Mure of an SCTP assooia.ion hereon a Signallina Gateway Process and an ApphcaUon 

!tl-^i assoeiadons beeween one **** Gateway Process and an Appiieabon 
Server. 



Traffic between a Signalling Gateway Process and an Application Server Process 

can stop for three reasons: . ^ 

.A, ZtP association completely fails. However this should be rare owmg to the SCTP 
mmti^ming feature. As a matter of fact, the SCTP multi-homing aims at xnanagmg ihe 
XL interfaces and allocating associations to these interface, Should tins fanure occur 

however, messages will be lost and will not be recovered-. , ....... 

* <i irTtrvn a<?P DOWN message. In this case, all data 
-An Application Server Process sends a Sigtran ASP DOWN m DOWN 'AOS. 

traffic will be closed as soon as the Signalling gateway returns an ASP DOWN ACK 

!^Xlication Server Process sends a Sigtran INACTIVE message. In his case all data 
£Z the concerned Application Server will he closed as soon as the SignalUng Gateway 
returns an ASP INACTIVE ACK message. 

The recovery procedures in the last two eases are set out in more detail in the inter- 
SQP communication flows of figures 8 and 9. 

Figure 3 is a block diagram of an example of a traffic diversion algorithm »at^ 
SG P envirolent^owingthe search for an al^ P am- A Signal^ End Point 20,^b 
could be a telephone switch for instance if the system were to be implemented for resxdenhal 
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OT commercial telephone service, is connected to a SS7 network 21. Only one such 
Signalling End Point 20 is shenvn in Figure 3 for simplicity of the drawing; however, it will 
be understood that many other Signalling End Points may be coupled to an Application 
Server 30, through other Signalling Gateways. 

5 

The Application Server 30 is preferably adapted to communicate with a plurality of 
Application Server Processes 26-1, 26-2, 26-3 referred as ASP1. ASP2, ASPS. Those ASPs 
are preferably connected to a Signalling Gateway 22 over an Internet Protocol network 24 as 
is also shown in Figure 2. While only three Application Server Processes ASP1, ASP2, 

1 0 ASP3 are shown in Fig 3 for simplicity, any number of application server processes may be 
connected to (he Application Server 30 or associated with as many Signalling Gateway 
Processes as may be required. Communications between Signalling End Point 20 and 
Signalling Gateway 22 over the SS7 network, as well as communications between Signalling 
Gateway 22 and Application Server Processes over the IP network are known by those of 

15 ordinary skilled in the art and therefore need not be described in greater detail. 

Still referring to Figure 3, Application Server Processes referred to as ASPl , ASP2, 
ASP3 26-1, 26-2, 26-3 are running on an Application Server AS1 30 and distributing 
signalling messages fern Signalling Gateway 22 to any number of Application Server 

20 Processes. For clarity in the present invention, the term "AS1" may be expressed simply as 
"AS", hut it should be kept in mind that a plurality of ASs may also be implemented which 
would create therefore different subgroup of Application Server Processes. While Figure 3 
shows communications between a single Signalling Gateway 22 composed of two SGPs 22- 
1, 22-2 and a subgroup of Application Server Process 26 composed of three ASPs 26-1, 26- 

25 2, 26-3, it will be that, depending on the required complexity of the SS7 and IP networks, 
additional SGPs or ASs, or ASPs may be included. In particular, the figures 4 to 11 show 
different the situation where a signalling gateway is composed of four SGPs communicating 
with an ASP2 of an Application Server AS 1 30 

30 In the configuration as shown in Figure 3, it is assumed that each Signalling 

Gateway Process 22-1, 22-2 of a Signalling Gateway 22 is connected to each Application 
Server Process 26-1, 26-2, 26-3 of an Application Server. This is not required but improves 
performance, in that every message received by an SGP from the SS7 network 21 can be 
forwarded directly to its destination ASP/ AS without SGP to SGP traffic under normal 

35 circumstances. 
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A detailed flow diagram of a traffic diversion algorithm is shown in Figure 10 and 
the main steps of a traffic diversion algorithm will be described in connection with the block 
diagram of Figure 3 in the case where an association fails. In this particular embodiment, it is 
assumed that an association SGP1-ASP2 foils for any of the three reasons previously 
mentioned. This failure triggers a traffic diversion to begin so that the Signalling Gateway 
Process 22- 1 performs the following recovery steps: 

- A timer is started which protects the overall switch-over procedure, as represented at step 
103 in Figure 10; 

- traffic received from SS7 network, and directed to this ASP (ASP2), is blocked. The 
messages' are then stored and queued in sequence, at step 104 in Figure 10; 

- every Other SGPs is informed that SGP1 can no longer reach ASP2/AS1, so SGP1 can no 
longer be used by other SGPs for diverted traffic to ASP2/AS1, at step 105 in Figure 10; 

- a test is carried out to establish whether the association is still physically connected, at step 
106, since it is assumed that nothing can be done to recover from a physical break of a 
optical fiber or a wire. In such a case, messages queued for this association are dropped at 
step 107; 

-It is verified that peer ASP has received every message previously sent on this association, 
at step 108 in Figure 10 (this step will he detailed further below); 

-An alternate path is identified to forward subsequent messages that have been queued to the 
destination service or Application Server, at steps 110 to 115 in Figure 10 (this step will be 
detailed further helow). The method used to find an alternate path depends on whether the 
traffic is TCAP data that might form part of a stateful transaction and thus need to be sent to 
the same ASP in order to further a pending transaction or non-TCAP data, which can be 
assumed to be stateless and therefore can be sent to any of the ASPs. 

Therefore, there are two alternate paths: 

Alternate path 1 for non-TCAP data: through another local association, meaning 
through an alternate Application Server Process ASP3 26-3 which serves the same AS. As is 
shown in figure 3, the first alternate path is from the SS7 network 21 to SGP1 22-1, then to 
ASP3 26-3. 

Alternate path 2 for TCAP data: through an alternate Signalling Gateway Process 
SGP2 22-2 still connected to Application Server Process ASP2 26-2, meaning through the 



200208994-1 EP 



Fax resu de : 33 8476149773 



83/04/63 17:83 P»: 21 



/ 



13 

same Application Server Process ASP2 26-2. As is shown in Figure 3, the second alternate 
path is from the SS7 network 21, SGPl 22-1 to SGP2 22-2 then to ASP2 26-2. 

Messages are sent to an association indexed by messages SLS according to the SLS 
routing table, at steps 1 16 and 113. 

5 

When an association is re-established, a switch back algorithm can begin, A detailed 
flow diagram of a switch back algorithm is shown in Figure 11 and the main steps of a 
switch back algorithm will be described in connection with the block diagram of figure 3. In 
this particular case when association SGP1-ASP2 is restored, the Signalling Gateway 
10 Process 22-1 handling the association performs me following recovery 

- A timer is started which protects the overall switch back procedure, as represented at step 
204 in Figure 11; 

-Traffic received from SS7 network, and destined to this ASP (ASP2) is blocked. These 
messages are queued, at step 205; 
1 5 -It is verified that every diverted message has been received by the ASP diversion path, at 
steps 206 to 208. This may require inter-SGP communication to wait for every diversion 
SGP to confirm that diverted messages have been sent in order to reply to the ASP with an 
ASP_ACTTVE_ACK at step 209; 

- Other SGPs are informed that SGPl can reach ASP2/AS1 again. Henceforth, SGPl can be 
20 used by other SGPs to divert traffic to ASP2/AS1, at step 210; and 

- Traffic is switched back to a new association, at steps 21 1 and 21 2. 

In order to describe the steps of verifying peer ASP receives every transmitted 
message, a thorough description of the traffic diversion and switch back algorithms will now 
25 follow referring respectively to figures 10 and 11. 

Figure 10 is a flow diagram of a traffic diversion algorithm that is carried out when 
an ASP_DOWN message is sent to an SGP at step 100, an association fails at step 101, or an 
ASP_1NACTIVE message is sent to an SGP at step 102. Further to the occurrence of any of 

30 these three cases, a protection timer set to a predetermined value is started at step 103. In 
response to this message signal, the SGP starts buffering the messages received from the SS7 
network by queuing them according to the order they are received at step 104. Following mis 
action, the SGP broadcasts to other SGPs that it is unable to reach the corresponding 
AS/ASP at step 105 to which other SGPs immediately reply with a Stop Traffic Diversion 

35 inter-SGP control signal. 
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The SGP then tests if the whole association is still connected at step 106. If not it 
will drop all messages queued to this association at step 107. However, as previously 
discussed, this case should hardly ever occur owing to the SCTP multi-homing as defined in 
5 the M3UA standards. 

At step 108, the SGP verifies that the messages previously sent usingthe deactivated 
association have been received in sequence by the ASP/AS, that no data messages have been 
lost or duplicated. When the remote ASP sends an ASP_DOWN or ASPJNACTIVE 

1 0 message, the ASP can still process the data messages that are being transmitted (or still in the 
IP stack transmit buffers). The SGP ensures that the acknowledge message 
ASPJDOWN^ACK or ASP_INACTIVE_ACK are not returned to the ASP after all 
messages have been transmitted to the ASP/AS. This is possible if the data messages are not 
using the same SCTP streams as the control messages. Three possible implementations can 

15 be used in order to ensure that the ASP/AS receives all messages in sequence before sending 
acknowledgement messages ASPJ30WNACK or ASP_1NACTIVE_ACK: 

- Delay acknowledge messages (ASPJDOWNjVCK or ASPJNACTIVE_ACK) for a 
certain predetermined time; 

- Send ASPJNACTIVE_ACK message on the same stream used for sending data messages 
20 to the deactivated ASP. In this case, it is unlikely that the ASP_INACTIVE_ACK message 

will arrive at the ASP before the data messages so that the ASP can process in sequence the 
data messages first, then the ASP_INACnVE_ACK message; or 

- Send Sigtran HEARTBEAT messages and wait for the HEARTBEAT_ACK messages, and 
only then send the ASPJDOWNACK or ASP_INACTIVE_ACK. 

25 

Once all the previously sent messages of the deactivating association have been 
received in sequence by the ASP/AS, an ASP_DOWN_ACK or ASPJQ*ACTTVE_ACK 
message can be returned from The SGP to the ASP at step 109. The protection timer set at 
step 103 is set so as to give enough time to cover the traffic diversion procedure from steps 
30 104 to 1 09. Should the timer expire before reaching step 1 1 0, the traffic diversion procedure 

loops directly to step 110 where the SGP handles queued messages received from SS7 
network. 

i 

As previously mentioned, the step of finding an alternate path depends on the type of 
35 traffic (TCAP or non-TCAP). After handling queued traffic from the SS7 network at step 

i 

.. .. I 
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1 10, a test is performed at step 1 1 1 in order to detect whether the traffic relates to a TCAP or 
non-TCAP message transaction. If it is TCAP traffic, the SGP needs to find an active 
diversion SGP for ASP/AS at step 112 for transmitting traffic at step 1 13. If it is non-TCAP 
traffic, the SLS routing table is then recomputed for that AS at step 114. Furthermore, the 
5 system tests whether there is not entry left in the jSLS routing table i.e. active associations, 
the system loops back to step 1 12. If there are still entries left in the SLS routing table, the 
SGP sends messages to association indexed by message SLS at step 116 and loops back to 
handle queued traffic from the SS7 network at step 1 10. 

! 0 The handling of non-TCAP traffic is better illustrated in Figures 4 and 5 which show 

how the SLS routing tables in SGP1 and SGP2 are computed following an association failure 
SGP1-ASP2, Figure 4 showing the SLS table before the failure SGP1-ASP2 and Figure 5 
showing the SLS table after the failure. . 

» * 
| 

15 For non-TCAP data, it is sufficient to forward data to an alternate ASP serving the 

same AS. In the case shown in Figure 4, SGPl can select another association with the 
alternate ASP2, and forward the traffic to that j alternate ASP2. When there are several 
alternate ASPs, it is better to dispatch to each of them a subsetof the diverted messages. For 
SCCP class I messages (and even classO messaged), the SLS routing table kept for each AS 

20 must be re-dispatched to the associations of thejactive ASPs attached to the AS, such as 

ASP 1 and ASP3 in the example shown in Figure 51 

I 

To summarize, the state of the SLS routing table before the failure of SGP1-ASP2 
association in Figure 4 is as follows: : 

25 ! 





ASP1 


ASP2 ; 


ASP3 


SGPl 


1 47 ... 


25 8 ... 

J. 


3 69 ... 


SGP2 


1 47 ... 


2 5 & . ■ ■- 


3 6 9 ... 



The state of the SLS routing table afterjthe failure of SGP1-ASP2 association in 
Figure 5 is as follows: ; 



i. 





ASP1 


ASP2 | 


ASP3 


SGPl 


1 2457 ... 


i 


3689- 


SGP2 


1 47 ... 


2 5 8..!. 


369 - 



i 



/ ! 
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If SGP1 were to lose all associations with jevery ASP serving AS1, it must divert the 

i 

messages destined to AS1 though another SGP. This case would be similar to the case of 
TCAP data as described hereafter. 

Should the SGP1-ASP2 association be) re-established, SGP 1 checks first that 
diverted traffic has been received by other ASPs (ASP1 and ASP3). In that respect, it has to 
ensure that peer ASPs (ASP1 and ASP3) receive) all transmitted messages in each backup 
association SGP1-ASP1 and SGP1-ASP3. Aftefwards, SGP1 can re-compute the SLS 
routing table, and restart the traffic distribution to ASP2/AS1 as is shown at step 211 in 
figure 11. 



15 



20 



25 



30 



For TCAP data, it is important to distribute all messages relating to a single 



transaction to the same ASP. This is mandator^ for SUA. Thus it is even required that 
messages of TCAP transactions be dispatched; to the ASPs according to their local 
Transaction Id TID. Each ASP (serving an AS) 5s identified and activated for a range of 

! - ■ 

specified TTDs, Figures 6 and 7 show that ASP2 is identified with a predetermined TID 
range so that messages within this TID range are effectively received by ASP2. The 
configuration in Figures 6 and 7 is the same as in Figures 4 and 5* except that data are TCAP 
type and that Signalling Gateway 22 is composed of 4 SGPs, SGPl to SGP4. 



When the SGP1-ASP2 association fails, messages received from the SS7 network, 
and identified with the TID range corresponding to ASP2, must be diverted to SGP2 and 
then forwarded onto the SGP2-ASP2 association. If several SGPs can still reach ASP2, the 
diverted traffic can be dispatched to them according to the SLS routing table: 

! 

Before the failure of the SGP3-ASP2 association, the state of the SLS routing table 
is as follows: 



SGP1-SGP2 


SGP1-SGP3 


SGPl 


-SGP4 


1 47 ... 


25 8... 


3 69 



As is shown in Figure 7, if one of the other SGPs loses its association with ASP2, for 

instance association SGP3-ASP2, it broadcasts this information to other SGPs. This 

i 

information is used by the SGPs that are currently diverting traffic to the failed SGP. These 
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SGPs must reallocate the SLS routing table to other SGPs that are still able to reach the ASP. 
The state of SLS routing table after this additional failure of SGP3-ASP2 association is as 
follows: 



SGP1-SGP2 


SGP1-SGP3 


SGP1-SGP4 


1 2 45 7 ... 




3 689 ... 



Should the SGP1-ASP2 association be re-established, SGP1 must check first that the 
diverted traffic has been entirely received by the ASP2. In that respect, it has to ensure that 
ASP2 has received all transmitted messages in each backup association SGP2-ASP2 and 
SGP4-ASP2. Once this has been verified, SGP1 can re-cotnpute the SLS routing table, and 
restart traffic distribution to ASP2/AS1 as is shown at step 21 1 in figure 1 1 

Figure 1 1 is a flow diagram of a switch back algorithm that is applied whenever an 
association has been re-established at step 201, followed by an ASPJJP message sent by the 
ASP and received by an SGP acknowledging with an ASP_UP_ACK message at step 202, 
further followed by an ASP_ACTIVE message sent by the ASP and received by the same 
SGP at step 203. Following the reception of the ASP_ACTIVE message, a protection timer 
is started at step 204 and messages received from the SS7 network are queued at step 205 in 
order to block traffic between SS7 network and the corresponding ASP. Afterwards, the 
newly activated SGP has to ensure that all diverted messages have been received by the ASP 
according to the former routing table. Therefore, at step 206 the SGP whose association has 
been newly activated sends to other active SGPs or diversion SGPs a "Flush diverted traffic" 
inter-SGP control signal. Upon reception of this control signal, these active SGPs or 
diversion SGPs start flushing diverted traffic through diversion path(s) at step 207 until the 
last message has been received by the ASP. A "Diverted traffic flushed" inter-SGP control 
signal is theri sent from each active SGP or diversion SGP at step 208. 

Once the newly activated SGP has received from all active SGPs or diversion SGPs 
the control signal "Diverted traffic flushed", it replies to the ASP with an 
ASP_ACTTVE_ASK message at step 209. The protection timer set at step 204 is set so as to 
allow enough time to cover the switch back procedure from steps 204 to 209- Should die 
timer expire before reaching step 209, the switch back procedure loops directly to step 209 
where the SGP replies to the ASP with an ASP_ACTIVE_ASK message. 
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Then, the newly-activated SGP can broadcast to all SGPs an inter-SGP control signal 
"Able to reach ASP/AS" at step 210. Following this control signal, the SLS routing tables 
are then recomputed at step 211 and the messages from the SS7 network are then processed 
normally using the newly updated SLS routing table at step 212. 

5 

In order to control the communications between SGPs and to interface with ASPs, 
Inter-SGP communications are used. Before describing examples of inter-SGP 
communication flows for a traffic diversion and a switch back in an environment of four- 
SGPs, as are shown in Figures 8 and 9, some basic functions and principles of inter-SGP 
1 0 communication will be described. 

Inter-SGP communications enable the transmission of diverted data traffic between 
SGPs. In addition to this primary function, inter-SGP communications also allow the 
distribution of information between the SGPs. All SGPs of one SG share a common database 
1 5 that contains the AS/ASP activation states for each SGP. Finally, inter-SGP communications 
are aimed at synchronizing traffic diversion and switch back procedures between SGPs. 

Therefore, there are six different types of inter-SGP control signals that are used in 
order to control inter-SGP communications. Each time that an SGP is deactivated, it 
20 broadcasts an "Unable to reach ASP/AS" control signal to other SGPs within the same AS. 

This control signal is aimed at informing other SGPs of the ASP deactivation for the purpose 
of updating the routing table of an AS. A "Stop, traffic diversion" control signal is then 
returned from aJ] other SGPs to confirm they no longer use the failed SGP to divert traffic, as 
was previously highlighted in the description of the traffic diversion procedure. Once the 

2 5 SGP of the failing association has completed flushing its transmission buffers and sent ASP- 

DOWN-ACK or ASP-INACTIVE-ACK messages, it sends a "Traffic diversion stopped" 
control signal to the other SGPs so that the other SGPs that were using the SGP of the failing 
association to divert traffic can start sending traffic on an alternate diversion path. 
Furthermore, this control signal allows recovery from multiple association failures. This 

3 0 control signal is used to ensure that messages are received in sequence at the ASP. 

Should a switch back procedure be initiated after a failure of an association, or an 
SGP be activated, the corresponding SGP sends an "SGP able to reach ASP/AS" control 
signal to broadcast to other SGPs the ASP activation for the purpose of updating the routing 
35 table of an AS. After updating the routing table, a "Flush diverted traffic" control signal is 
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sent from each SGP that is still not able to reach the AS to their respective diversion SGPs to 
request that previous messages are effectively senjf to the ASP before using the new route for 
transmitting messages. This "Flush diverted traffic" control signal is required in order to 
ensure that messages are received in sequence a* the ASP. Following this "Flush diverted 
5 traffic" control signal, each receiving SGP starts the operation of Flushing transmission 
buffers until the last message is sent. Once this is done, each receiving SGP. returns a 
"Diverted traffic flushed" control signal. ; 

Figure 8 illustrates an example of an inter-SGP communication flow in case of a 

10 traffic diversion procedure in an environment having four-SGPs 22-1, 22-2, 22-3, 22-4. 

These SGP1 to SGP4 22-1, 22-2, 22-3, 22^ are jin ACTIVE states 822-10, 822-20, 822-30 
and 822-40 and are connected to an Application Server Process ASP 26. ASP2 herein 
referred as ASP 26 acts as a single applicationj server process with a predetemiined TED 
range in connection with signalling gateway 30. iks Figure 8 exemplifies a set of inter-SGP 

15 control signals and messages exchanged as ASP 26 begins deactivating a Signalling 
Gateway Process and more specifically SGP1. As' is shown in figure 7, we can assume that 
the association SGP1-ASP2 is inactive which respires ASP 26 to send an ASPJNACTIVE 
message 800 to SGP1 22-1. Further to this message, SGP1 22-1 starts buffering messages 
received from the SS7 network for ASP 26 at step :822-13 and sends a set of "unable to reach 

20 ASP" inter-SGP control signals 802, 804, and 806 respectively to SGP2 22-2, SGP3 22-3 
and SGP4 22-4 specifying that SGPl is unable toieach ASP 26. In return, SGP2, SGP3 and 
SGP4 respond with "Stop traffic diversion" inter-|SGP control signals 808, 812, 814 ,to SGPl 
that they stop traffic diversion to SGPl. In response to these control signals, SGPl 22-1 
flushes its transmission buffers at step 822-15,!meaning that SGP1 ensures that previous 

25 transmitted messages for ASP 26 have been revived by the Application Server Process. 
Afterwards, SGPl sends an ASP_INACTrVE_AGK message 820 to ASP 26. 

j| 

Once the ASPJNACTTVE signal has been acknowledged by SGPl 22-1, SGPl can 
set its status to INACTIVE at step 822-16 and. start diverting the traffic using the newly 
30 updated SGP routing table at step 822-17- ji 

• ji 

In the meantime, ASP 26 has sent an ASPJNACTI VE message 840 to SGP3 22-3. 
Following which, SGP3 starts buffering the messages received from SS7 traffic at step 822- 
41 and emptying its inter-SGP communication; queue at step 822-42. SGP3 22-3 will 
35 continue processing this inter-SGP communication queue until it receives "stop traffic 
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diversion" control signals from all SGPs. In order io inform other SGPs that SGP3 is unable 
to reach ASP 26, SGP3 sends a set of inter-SGP control signals "Unable to reach ASP" 844, 
846, 848 respectively to SGPl, SGP2 and SGP 4. Jn return, SGPl, SGP2 and SGP4 respond 
with inter-SGP control signals 852, 854, and 856 tp SGP3 that they stop the traffic diversion 
to SGP3. In this particular case, while SGP1 is buffering traffic diverted to SGP3 at step 
822-18, SGP3 22-3 is flushing its transmission buffers at step 822-43 to ensure that previous 
transmitted messages for ASP 26 have been received by the Application Server Process. 
Once the last message has been transmitted, SGP3 22-3 sends an ASPJNACTTVE_ACK 
message 860 to ASP 26 and sets its status to INACTIVE at step 822-44. Afterwards, SGP3 
stops buffering messages received from the SS7 network and starts diverting traffic using the 
newly updated SGP routing table at step 822-45. 



Then, SGP3 can send a set of 'Traffic diversion stopped" inter-SGP control signals 
864, 866, and 868 respectively to SGPl, SGP? and SGP4 to inform them that traffic 
diversion can start using the newly updated routing table. Once SGPl receives the "traffic 
diversion stopped" control signal 864, it starts diverting the traffic using effectively the SGP 
routing table at step 822-1 9. 



Figure 9 illustrates an example of an inter|SGP communication flow in the case of a 
switch back procedure in an environment of foiir-SGPs 22-1, 22-2, 22-3, 22-4. Initially, 
these SGPl to SGP4 are INACTIVE respectively! at steps 922-10, 922-20, 922-30 and 922- 
40 and are connected to an Application Server Pnjcess ASP 26. As in Figure 8, ASP2 herein 
referred as ASP 26 acts as a single application server process with a predetermined TID 
range in connection with signalling gateway 30. However, this Figure 9 exemplifies a set of 
inter-SGP control signals exchanged as ASP 26 begins activating Signalling Gateway 
Processes and more particularly SGPl 22- 1 and Sq?P2 22-2. 



ASP 26 starts sending an ASP_ACTTVE message 900 to SGPl 22-1. Further to this 
message, SGPl 22-1 responds with an ASP_AClirVE_ACk message 902 to ASP 26 before 
setting its status to ACTIVE at step 922-12. In order to inform other SGPs that its status has 
been activated, SGPl sends respectively a set pf "SGPl able to reach ASP" inter-SGP 
control signals 904, 906, 908 respectively io SGB2, SGP3 and SGP4 that it is able to reach 
ASP 26, In response to each of these control signals, SGP2, SGP3 and SGP4 respectively 
start diverting the traffic using the newly updated; SGP routing table at steps 92222, 922-32 
and 922-42. 
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In the meantime, ASP 26 has sent an ASP_ACTIVE message 910 to SGP2 22-2. 
SGP2 then starts buffering the messages received Worn SS7 traffic at step 922-23 and sends a 
"Flush diverted traffic" inter-SGP control signal 9b to SGP1 22-1 to ensure that all diverted 
5 messages have been received by the ASP diversion pativ which corresponds to step 206 of 
figure 11, At the reception of this control signal, SGP1 starts flushing its transmission 
buffers at step 922-13, which corresponds to step 207 of figure 1 1. Once the last message has 
been flushed, SGP1 sends an inter-SGP control (signal "Diverted traffic flushed" 914 to 
SGP2. This operation is also carried out for SGP3 122-3 and SGP4 22-4. Indeed, each of these 
1 0 SGPs respectively sends "Flush diverted traffic" inter-SGP control signals 930, 940 to SGP1 
22-1, followed by the steps of flushing SGP1 transmission buffers at steps 922-15 and 922- 
16 and the response of inter-SGP control sigrjals "Diverted traffic flushed" 932, 942 
respectively to SGP3 and SGP4. \ 

ii ; : - 

15 Once SGP2 receives the inter-SGP control signal "Diverted traffic flushed" 914 

from SGP1, it acknowledges the ASP^ACTIVEj by returning an ASP_ACTIVE_ACK to 
ASP 26, sets its status to ACTIVE at step 922-24 and stops buffering messages received 
from the SS7 network at step 922-25. Afterwards^ SGP2 starts sending to all SGPs a set of 
inter-SGP control signals "SGP2 able to reach ASP" 924, 926, 928. Further to these control 

20 signals, SGP3 and SGP 4, which are still INAGTTVE in the present case, start buffering 
diverted traffic at steps 922-35 and 922-45 until fre SGP routing tables are updated before 
starting to divert messages at steps 922-36 andj 922-46 according to the newly updated 
routing tables. 



SL 



2 5 The above discussion is meant to be illustrative of the principles and various 

embodiments of the present invention. Numerous variations and modifications in each of the 
illustrated examples will become apparent to thoseijskilled in the art once the above disclosure 
is fully appreciated. It is intended mat the following claims be interpretedto embrace all such 



ij 

variations and modifications 
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CLAIMS? 

1 . A method of controlling a local process that forms part of a first processing entity, 
said first processing entity maintaining a plurality of associations with a plurality of remote 
5 processes in a second processing entity, said method comprising the steps of: 

- receiving a failure message from a remote process indicating a fault affecting an 
association linking the local process with that remote process; 

- queueing data messages destined for that remote process; 

- controlling the transmission of an acknowledgement of the failure message so that data 

!i 

1 0 messages pending on the association are received at that remote process before the 
acknowledgment of the failure message; and [ 

- initiating a traffic diversion to set up an altematefpath between said first processing entity 
and said second processing entity for queued data messages. 

V 

15 2. A method as claimed in claim 1 wherein the controlling comprises delaying the 
acknowledgment of the failure message. 



3 . A method as claimed in claim 2 wherein die delay is for a predetermmable time 
period. i 



20 

4. A method as claimed in claim 2 wherein tfie delay is determined by transmission and 

acknowledgment of a heartbeat message. j 

j, 

f; 

5. A method as claimed in claim 1 wherein toe controlling comprises sending the 
2 5 acknowledgement of the feilure message on the data stream used for the data messages. 

l; 
•i 

6. A method as claimed in any preceding claim comprising testing the association to 

determine if the association is active and, if not, dropping messages queued for the 

association. j* 

30 i 

i- 

7. A method as claimed in any preceding claim wherein the first processing entity 
maintains a plurality of associations between a plurality of local processes and a plurality of 
remote processes. |r 

t. 

. . . ... 



200208994-1 EP 



Fax resu de : 33 8476149773 



83/84/03 17:83 



Par: 31 



23 

8 A method as claimed in claim 7 comprising informing other local processes of the 

I 

fault so that such other local processes can avoid involving the foiled association in traffic 
diversion procedures initiated by them. 



10 



15 



20 



25 



9. A method as claimed in claim 7 or claim 8[comprising determining whether pending 
messages form part of a stateful transaction, and, if so, finding an alternative local process to 
provide an alternative path to the same remote process. 



10. A method as claimed in claim 9 wherein I 
whether the messages are TCAP messages. 



tl ie determining comprises detemiining 



11. A method as claimed in claim 7 ox claim 
messages form part of a stateless transaction, and, 
the same local association to another remote 



^comprising determining whether pending 
if so, finding an alternative path through 



process 



12. A method as claimed in claim 1 1 whereir 
whether the messages are non TCAP messages. 



determining comprises determining 



13. A method as claimed in any preceding claim wherein the traffic diversion comprises 
modifying routing tables. 

14. A method as claimed in any preceding claim wherein the first processing entity is a 
signalling gateway, the local processes being signalling gateway processes having a common 
point code or set of point codes. 

15. A method as claimed in any preceding claim wherein the second processing entity is 
an application server, the remote processes beingjapplication server processes having a 
common routing key. ' | 



30 



16. A method as claimed in claim 1 5 whereinjthc message indicating the fault is an 



ASP INACTIVE or ASPJ30WN message and 



ASPJOtf ACnVE_ACK message or an ASP_DOWN_ACK message 



; acknowledgement being respectively an 



/ 
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17. A method as claimed in any preceding claim {further comprising the initiating of a 
switch back procedure to include a new association linking a local process with a remote 
process; 

18. A method as claimed in claim 17 compri&mg informing other local processes of the 
new association so that such other local processesjean begin involving the new association. 

19. A method as claimed in any preceding claim wherein the associations are SCTP 
associations. 

20. A computer program code element for controlling a local process using a method as 
claimed in any preceding claim. 

21. A signalling gateway comprising a plurality of local processes that are controlled 
using a method as claimed in any of claims 1 to 19; and a computer program code as claimed 
in claim 20. ! r 



22. A method of recovering feilure in a distributed signalling gateway maintaining a 
plurality of associations between signalling gateway processes of said distributed signalling 

2 0 gateway and application server processes of an application server, said method comprising 

, ii 

the steps of; | 

- initiating a traffic diversion in response to a failure message to set up an alternate path 
between said signalling gateway processes and said application server processes m case of 
fault affecting an association; i , 

25 - initiating a switch back to include a new association linking a signalling gateway process 

i r 

and an application server process; , 

- according to the change of status of any association, updating routing tables capable of 

i • 

routing data messages received by said signalling gateway processes to its destined 
application server processes; and ; 1 

30 - distributing sequentially messages from saim. signalling gateway to said plurality of 

application server processes according to said routing tables. 

h 

23. The method as claimed in claim 22 wherein said step of initiating a traffic diversion 
further comprising the steps of: 

35 - starting a protection timer; 
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- queuing messages destined for the application server process of the failed association; 

- informing other signalling gateway processes of the fault so that other signalling gateway 
processes can avoid involving the failed association in traffic diversion procedure initiated 
by them; 

5 - controlling the transmission of an acknowledgement of the failure message so that data 
messages pending on the association are received at the application server process before the 
acknowledgement; and • 

- finding alternate path to forward subsequent stateless processing messages onto another 
application server process through another association or to forward subsequent stateful 

1 0 processing messages through an alternate signalling gateway process still associated with the 
same application server process. 

\ 

24. The method as claimed in claim 23 wherein said step of finding alternate path to 
forward subsequent stateless or stateful processing messages further comprising the steps of: 

15 - re-computing said routing tables for said application server if the traffic is carrying stateless 
processing messages, sending messages according to said newly updated routing tables if 
there arc still entry left in said routing tables and continuing to process until no entry is left 
in said routing tables; and 

- finding an active signalling gateway process to divert the traffic for said application service 
20 process if the traffic is carrying stateful processing message, and sending said stateful 

processing messages onto said signalling gateway process through said alternate path. 

25. The method as claimed in any of claims 22 to 24 wherein said step of initiating a 
switch back to include a new association further comprises the steps of: 

25 - starting a protection timer further to the reception! of an association activation; 

- queuing data messages destined to the applicatioii server process of the new association; 

- controlling the transmission of an acknowledgement of the association activation so that all 
diverted data messages have been transmitted via a diversion path; 

- informing other signalling gateway processes of said new association; and 
30 - re-computing said routing tables. 

26. The method as claimed in any preceding; claims 22 to 25 wherein said signalling 
gateway is coupled to a signalling end point across a signalling system n°7 network. 
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26. The method as claimed in any preceding claims 21 to 25 wherein each signalling 
gateway process of said signalling gateway is cojupled to each application server process 
across an internet protocol network. ! 



27. The method as claimed in any preceding! claims 22 to 26 wherein said stateful and 
stateless processing messages are respectively TCAP and non-TCAP messages identified by 
transaction identification numbers. 



28. The method as claimed in any preceding claims 



1 0 used for distributing signalling messaiges from saic 
to said plurality of application server processes are 



21 to 27 wherein said routing tables 
plurality of signalling gateway processes 
SLS routing tables. 
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I ABSTRACT 

METHODS AND APPARATUS FOR CONTROLLING PROCESSING ENTITIES, SUCH 
AS DISTRIBUTED SIGNALLING GATEWAYS 

5 

A metiiod of controlling a local process that forms part of a first processing entity such 
as a signalling gateway , said first processing entity inaintaining a plurality of associations witli 
a plurality of remote processes in a second processing entity such as a application server. The 
method comprises the steps of: receiving a failure message from a remote process indicating a 

1 0 fault affecting an association linking the local process with that remote process; queuetng data 
messages destined for that remote process;' controlling the transmission of an 
acknowledgement of the failure message so that data messages pending on the association are 
received at that remote process before the acknowledgment of the failure message; and 
initiating a traffic diversion to set up an alternate path between said first processing entity and 

1 5 said second processing entity for queued data messages. The local processes can be signalling 
gateway processes having a common point code or set of point codes and the remote processes 
can be application server processes having a common routing key. 

Figure 2 

20 
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